Subject: HPR over ATM feedback

From: Matthew Finlayson <[email-masked]>
Date: Fri, 05 Jul 96 18:15:00 BST

We've read the new HPR over ATM specification.  Overall we think it looks   
to be in very good shape - well done.

Looking at its contents in the light of the requirements for CP it looks   
like it's pretty well all there.  The only particular omission we've   
noticed is that there are no code size estimates included.  Is this   
deliberate?

We do have a few comments on the document.  Firstly some technical issues   
which ideally should be addressed before CP.

 - Page 2-31
The text reads that "at this point CS is notified of the incoming call   
and creates an instance of LDLC".  This introduces a new protocol   
exchange across the CS/DLC interface and as the document does not attempt   
to address how this should be implemented and how it should behave in   
error conditions, it may cause problems with interoperability.  For   
example, what should the behaviour be when the SVC goes down between LDLC   
being created and the first XID being received?

 - The document is ambiguous as to whether ATM is to be accessed by a   
switched or a SATF port.  Much of the document (Page 2-36, Page 2-58)   
suggests SATF.  Other places, particularly Page 2-27 suggests switched   
("Regular TGs defined on SVCs are switched connections between two nodes   
...").  Indeed this paragraph states that the limitation of one active   
link per switch port is being lifted due to ATM's requirements.  This   
should be made consistent.

 - Page 2-62
"There is no need for multiple regular TGs to share a VCC; why bother   
defining them?"  Isn't this making assumptions about the customers'   
requirements?  What would happen, for example if the link passed through   
a gateway (with a VCC up to the gateway, and other DLC types beyond) as   
in the case shown below, where NN1 has TGs to both NN2 and NN3 which   
could potentially be carried on the same shared VCC between NN1 and the   
gateway.

               ATM                        Token Ring

   +-----+                +--------------+         +-----+
   |     |----TG A--------|              |--TG A---| NN2 |
   | NN1 |                |ATM/TR gateway|         +-----+
   |     |----TG B--------|              |--TG B-+
   +-----+                +--------------+       | +-----+
                                                 +-| NN3 |
                                                   +-----+

Secondly, there are also a number of more minor other areas where we   
think the document should be clarified or corrected.

 - Section 2.4.1 Page 2-8
This says that the Liveness protocol is optional.  Perhaps it should make   
it clear (as it does later on) that it's only sending TEST(CMD) that is   
optional - it's base function to respond to them?

 - Section 2.7.1 Page 2-26
"When a connection network is defined on the ATM network, at most one   
defined link station per adjacent node is required for CP-CP sessions."   
 I'm not sure what this sentence is trying to say.

 - Figure 2-20, Page 2-31
The sample flow here suggests that CONNECT_IN and XID are a single   
signal.  I believe that in the APPN Architecture Reference they are   
actually separate signals and that the XID is sent up after the   
CONNECT_IN positive response has been received.

 - Figure 2-20, Page 2-31
This shows a successful CONNECT_IN.  It would be useful to include a flow   
with an unsuccessful CONNECT_IN (as in the case of CONNECT_OUT).

 - Figures 2-22 and 2-23, Page 2-32
It's not clear to me what the difference in the PCM_CALL_CLEAR.ind   
received in each case actually is.  Perhaps this could be clarified?

 - Figure 2-22, Page 2-32
Typo - "REPORT_DISCONNEDT(RSP)"

 - Page 2-37
"This can be costly for the customer if the tariff structure includes   
charges based on the number of SVCs established."  I do not believe that   
the spec addresses this issue - this should be made clear.

 - Footnote 11, Page 2-40
This footnote is very difficult to understand without far more knowledge   
of ATM (and in particular UNI protocols) than the document provides.  It   
should probably me made clearer or removed.

 - Page 2-56
"and SM of the PLU would attempt to reinitiate the session".  This   
certainly doesn't always happen (although the PLU may retry session   
activation if it is trying to auto-activate sessions or in the case of   
some old style PLUs).  This sentence should be reworded to make this   
clearer.

 - Page 2-59 - 2-60
It's rather confusing to refer throughout this section to footnotes which   
were included 30 pages before.

 - Section B1, Page B-1
This section should probably make it clear that reserved _values_ (as   
distinguished from reserved bits or fields earlier on the page) _will_   
(and should) have receive checks applied to them.

See you at the AIW.

Matthew.

==============================================================
Matthew Finlayson                  Data Connection Limited
([email-masked])                 Telephone: +44 181 366 1177
                                   Fax:       +44 181 367 8501
==============================================================